home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0367.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  4.6 KB  |  126 lines
  1. Dan,
  2.  
  3. Your work on the SGML side (as all your work) is much apreciated!
  4.  
  5. >  Date: Thu, 19 Nov 92 04:37:23 CST
  6. >  From: Dan Connolly <connolly@pixel.convex.com>
  7. >  
  8.  
  9. >  
  10.  
  11. >  The thrust to register HTML with the authorities has
  12. >  spurred me to look over the DTD again. I've found some
  13. >  problems.
  14. >  
  15.  
  16. >  1. Currently the NAME attribute of an anchor is declared
  17. >  as CDATA, i.e. just about anything. There's an SGML thingy
  18. >  called an ID. SGML parsers enforce uniqueness among the
  19. >  IDs of a document. Seems like that's what we want for ID
  20. >  names.
  21. >  
  22.  
  23. >  But an SGML ID has to start with a letter. So all the
  24. >  HTML files that use numbers as anchor names will break.
  25.  
  26. The enforcement of uniqueness is useful, and it is what we want.
  27. It is unfortunate that the very same constraint lead to the use of numbers!
  28. This is a hangup of the NeXT editor (which i still use, as
  29. until somone makes a more convenient editor!) but we oughtn't to
  30. worry about it.  A future editor could generate Z[0-9]* names.
  31. We could even specify that Z[0-9]* are related to a NEXTID attribute
  32. somewhere for the generation of time-unique IDs.
  33.  
  34. The only neat thing about CDATA is that it would allow a gateway
  35. to put in something which as come from the data. For example,
  36. a glossary generator might generate anchors for each term
  37. whose name equals the term, and then generate index entries
  38. pointing to that.
  39.  
  40. What do you think?
  41.  
  42. >  2. I introduced two tag names when I drafted the DTD:
  43. >      HTML contains the whole document. I defined it
  44. >  so you can omit both the start and the end tags, so it's
  45. >  inferred by SGML parsers. I don't think I can avoid some
  46. >  top-level tag.
  47. >      DOCUMENT contains most of the "body" -- all the
  48. >  headings and paragraphs. I did this to avoid something
  49. >  called mixed content, which causes complications.  I
  50. >  could rename this element as BODY, and introduce a
  51. >  omitable HEADING tag to surround the TITLE, NEXTID, and
  52. >  ISINDEX tags.
  53.  
  54. I like the latter idea.  Header and Body fit in well with mail
  55. nomenclature, wherase "document" is normally the whole thing
  56. retrieved.
  57.  
  58. >  3. I stuck anchors in as an inclusion, meaning they could
  59. >  be used just about anywhere. I thought stuff like <a
  60. >  name=foo><h1>Foo</h1></a> was legal, but neither linemode
  61. >  nor the midas browser groks.
  62.  
  63. The line mdoe doesn't?  It should.  Only titles I wanted to insist were
  64. plain ascii text....
  65. Turns out to be a bug in HTML.c -- fixed for next release.
  66.  
  67. >  I'm editing the DTD to restrict the usage of anchors to
  68. >  only contain text strings.
  69.  
  70. I don't like that.... I think that especially as we introduce
  71. highlighting, anchors will want to be general areas of text, so
  72. long as they are nested properly. (An "SGML attitude" restriction
  73. which Frank Kappe objected to I recall).
  74.  
  75. >  4. The OL tag is disappearing. It's no longer documented
  76. >  in the web, and it's not supported by MidasWWW. Should
  77. >  I delete it from the DTD?
  78.  
  79. You say its useful?  If you havce implemented it, and noone else
  80. objects, then we could put it back in. In principle, with hypertext, you don't  
  81. have to number tyhings, you can refer to them with a link. However, you
  82. can imagine the abstract difference between an ordered list and 
  83.  
  84. a sack of objects being important.  [For example, a list of
  85. instructions is ordered].  I'll put it into the HTML2 list of features.
  86. I suggest everyone  implement OL as UL in programs which, like the line mode  
  87. browser, can't differentiate.
  88.  
  89.  
  90. >  5. What about <HP1> thru <HP5>... should we include them?
  91. >  I'd prefer <em>, <tt>, <cite>, ala TeX. Or we could go
  92. >  with the O'Reilly/Hal DocBook tags:  <Emphasis>,
  93. >  <OopsChar>, <wordasword>,<CiteBook>,<Subscript>,
  94. >  <Superscript>.
  95.  
  96. I agree that numbering them is on the verge of useless.  The trouble is,
  97. you never have enough. Why CiteBook but not CiteProgram? etc etc.
  98. The docbook names are on the long side, aren't they? Not very important
  99. I suppose.
  100.  
  101. >  6. Any more thoughts on the BaseAddress tag?
  102.  
  103. Yes. It should be in. I think.  I've mentioned in  
  104. http://info.cern.ch/hypertext/WWW/MarkUp/Future.html
  105.  
  106. >  7. The HTML tags documentation says Listing sections can
  107. >  contain any ISO Latin 1 characters. The SGML standard
  108. >  mentions ISO 646, i.e. ascii, as the default, but the
  109. >  sgmls parser, the linemode browser, and MidasWWW all seem
  110. >  to grok Latin1 just fine.
  111.  
  112. I suggest we limit it to ASCII unless something outside the
  113. document says otherwise, while strongly recommending that
  114. 8-bit character sets should be handled by the apps.  I have
  115. seen some funnies when two clients both handle 8-bit characters,
  116. but not the same ones.
  117.  
  118. Does the SGML standard say how to specify the character set for
  119. the text?
  120.  
  121. >  Dan
  122. >  
  123.  
  124.     Tim
  125.  
  126.